1. 前言

本文是 << Spring Cloud微服务实战 >> 学习笔记, 以便自己查阅.

2. 什么是微服务

微服务是一种系统架构的设计风格,它主旨在于将一个原本独立的系统,拆分成多个独立运行的小型服务.不同服务之间通过Restful接口进行通讯协作.

拆分的小型服务围绕系统耦合度高的业务功能进行构建;
每个服务都维护自身的数据存储,业务开发,测试,部署机制;
由于是轻量级通讯协作,微服务可以使用不同语言来编写.

运维:维护进程数增加,需要一定的开发能力来编排组织进程;
接口:需要交互双方协调发布,完善接口和版本管理,保证接口的正确调用;
分布式环境:拆分后服务只能通过通信来进行协作,所以要考虑分布式环境的因素(网络延迟,分布式事务,异步消息)

为了解决前面的问题,以下是实施微服务一些原则:

保证每个服务都独立开发,部署,避免一个服务修改引起整个系统的重新部署.

以前按照技术层面将团队划分为DBA团队,运维团队,测试团队,后端,前端团队等等,若继续使用这种团队组织方式来实施对微服务架构的开发,当一个服务出现问题时,会引起团队的时间耗费和预算审批.所以在进行微服务架构的开发时,一般按业务线的方式进行拆分.

对服务整个生命周期负责,持续关注服务的运作情况,并不断分析以帮助用户来改善业务功能.

使用微服务不能简单将函数调用直接改成Restful/RPC调用(避免繁琐的通信), 微服务常用两种服务调用方式:

关于智能端点与哑管道的概念

哑管道是指消息的通讯,管道是不会通知端点消息的内容,结构,仅提供一个可靠的信息交互功能,称为”哑”.
智能端点是指端点要主动订阅管道的消息,去解析里面的内容,称为”智能”.

整个架构采用轻量级协议定义接口,各个组件根据具体业务特点进行技术选型.

每个服务管理其自有的数据库.(在改造过程中,将数据库的数据拆分到其它数据库中(Mysql,MongoDB,Redis))

面临的新问题

分布式事务,所以尽量避免事务,保证各服务之间是”无事务”的调用;
一致性问题,保证最终一致性;

由于服务数量的增多,务必需要一个”持续交付”平台来支持实施.
自动化测试与自动化部署.

微服务架构中,可能存在部分服务故障的情况,处理不好会出现故障蔓延的情况.(一个正常服务频繁调用故障服务,导致大量线程挂起等待超时,最后正常服务也出现了故障)

所以微服务架构中,应快速监测出故障源并尽可能恢复服务.(对每个组件的运行情况(服务状态,断路器状态,吞吐量,网络延迟等)实现监控和日志记录)

实施微服务应该以演进的方式构建.